Email authentication

 ( Internet Fraud ) 

The original base of Internet email, Simple Mail Transfer Protocol (SMTP), has no such feature, so forged sender addresses in emails (a practice known as email spoofing) have been widely used in phishing, email spam, and various types of frauds. To combat this, many competing email authentication proposals have been developed. three had been widely adopted – SPF, DKIM and DMARC. The results of such validation can be used in automated email filtering, or can assist recipients when selecting an appropriate action.

This article does not cover user authentication of email submission and retrieval.

Email authentication is a necessary first step towards identifying the origin of messages, and thereby making policies and laws more enforceable.

Hinging on domain ownership is a stance that emerged in the early 2000. It implies a coarse-grained authentication, given that domains appear on the right part of email addresses, after the at sign. Fine-grain authentication, at user level, can be achieved by other means, such as Pretty Good Privacy and S/MIME. At present, digital identity needs to be managed by each individual.

An outstanding rationale for email authentication is the ability to automate email filtering at receiving servers. That way, spoofed messages can be rejected before they arrive to a user's Inbox. While protocols strive to devise ways to reliably block distrusted mail, security indicators can tag unauthenticated messages that still reach the Inbox. A 2018 study shows that security indicators can lower the click-through ratio by more than ten points, 48.9% to 37.2% of the users who open spoofed messages.

SMTP defines the trace information of a message, which is saved in the header using the following two fields:

• Received: when an SMTP server accepts a message it inserts this trace record at the top of the header (last to first).
• Return-Path: when the delivery SMTP server makes the final delivery of a message, it inserts this field at the top of the header.

A mail user agent (MUA) knows the outgoing mail SMTP server from its configuration. An MTA (or a relay server) typically determines which server to connect to by looking up the MX record (Mail eXchange) DNS resource record for each recipient's domain name.

The path depicted below can be reconstructed on the ground of the trace header fields that each host adds to the top of the header when it receives the message: Return-Path: Received: from D.example.org by E.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500 Received: from C.example.net by D.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500 Received: from B.example.com (b.example.com 192.0.2.1)

 by C.example.net (which is me) with ESMTP id 936ADB8838C
 for ; Tue, 05 Feb 2013 08:44:50 -0800 (PST)
     

Normally, messages sent out by an author's ADMD go directly to the destination's MX record (that is B → D in the figures). The sender's ADMD can add authentication tokens only if the message goes through its boxes. The most common cases can be schematized as follows:

• The ADMD's MSA authenticates the user, either based on its IP address or some other SMTP Authentication means. Depending on the recipient address, the message can follow the normal path or pass through a mailing list or a forwarding service.For example, a recipient can instruct Gmail to forward messages to a different email address. The sender is not necessarily aware of that. B can be an outbound SMTP proxy or a smarthost.Properly configured proxies appear as part of the author ADMD.
• If the local network does not block outbound port 25 connections,Some ADMDs block outbound connection to port 25 (SMTP) to avoid this. This proactive technique is described in RFC 5068. In addition, some block inbound SMTP connections from IP address listed as dialup/DSL/cable. the user can deploy some "direct-to-mx" software.In this case the author's ADMD is not involved at all. Typically, Zombie computer and other malicious hosts behave that way.
• If the MUA is badly configured, it can also use a different relay, such as an outmoded open relay, that often does not authenticate the user.

• Most of the times it is still possible to use one's own ADMD MSA.Some ISPs block port 587, although RFC 5068 clearly says:

Access Providers MUST NOT block users from accessing the external Internet using the SUBMISSION port 587.

• Outbound connections to port 25 can be intercepted and tunnelled to a transparent proxy.
• A MUA can be configured to use an SMTP relay that the local network provider offers as a bonus.

• An e-card can send mail on behalf of a customer who typed email addresses on the local keyboard; some can be considered to work similarly.

The IP address of the sending MTA is guaranteed to be valid by the Transmission Control Protocol, as it establishes the connection by checking that the remote host is reachable.IP Address forgery is possible, but generally involves a lower level of criminal behavior (breaking and entering, wiretapping, etc.), which are too risky for a typical hacker or spammer, or insecure servers not implementing RFC 1948, see also Transmission Control Protocol#Connection hijacking. The receiving mail server receives the HELO SMTP command soon after the connection is set up, and a [[bounce address|Mail from:]] at the beginning of each message. Both of them can contain a domain name. The SPF verifier queries the Domain Name System (DNS) for a matching SPF record, which if it exists will specify the IP addresses authorized by that domain's administrator. The result can be "pass", "fail", or some intermediate result - and systems will generally take this into account in their anti-spam filtering.

A DKIM-compliant domain administrator generates one or more pairs of asymmetric keys, then hands private keys to the signing MTA, and publishes public keys on the DNS. The DNS labels are structured as ''selector''._domainkey.example.com, where selector identifies the key pair, and _domainkey is a fixed keyword, followed by the signing domain's name so that publication occurs under the authority of that domain's ADMD. Just before injecting a message into the SMTP transport system, the signing MTA creates a digital signature that covers selected fields of the header and the body (or just its beginning). The signature should cover substantive header fields such as From:, To:, Date:, and Subject:, and then is added to the message header itself, as a trace field. Any number of relays can receive and forward the message and at every hop, the signature can be verified by retrieving the public key from the DNS. As long as intermediate relays do not modify signed parts of a message, its DKIM-signatures remain valid.

It allows the administrative owner of a domain to publish a policy in their DNS records to specify which mechanism (DKIM, SPF or both) is employed when sending email from that domain; how to check the From: field presented to end users; how the receiver should deal with failures - and a reporting mechanism for actions performed under those policies.

ADSP was demoted to historic in November 2013.

A sender can apply for a reference at a vouching authority. The reference, if accepted, is published on the DNS branch managed by that authority. A vouched sender should add a VBR-Info: header field to the messages it sends. It should also add a DKIM signature, or use some other authentication method, such as SPF. A receiver, after validating the sender's identity, can verify the vouch claimed in VBR-Info: by looking up the reference.

The IP reverse, confirmed by looking up the IP address of the name just found, is just an indication that the IP was set up properly in the DNS. The reverse resolution of a range of IP addresses can be delegated to the ADMD that uses them, or can remain managed by the network provider. In the latter case, no useful identity related to the message can be obtained.

spf=pass smtp.mailfrom=example.com;
dkim=pass header.i=@example.com